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REMARKS 

Claims 1-28 are now pending in this Application. The Final Office Action (FOA) dated 
December 12, 2005 rejected Claims 1-28. Applicant has amended Claims 22 and 28 to correct 
antecedent basis. Applicant submits that the pending claims are patentable for the reasons discussed 
in detail below. 

Claim Rejections - 35 U.S. C 1 02 over Rouse 

Claims 1-7, 11-17, 21-25, and 25 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Rouse (U.S. Patent Application Publication No. 2003/0158816). Rouse is directed to 
"protecting Content Server Links, including but not limited to Webcast Server Links, from piracy or 
unauthorized use." (Rouse, pg. 1, para. 2.) In response to prior arguments, the FOA contends that 
Rouse discloses that metering information in a streaming media file is used by a user meter to tick 
the meter. (See, FOA, pg. 3, lines 5-7.) The FOA refers to Fig. 1 and paragraphs 5 and 138 of 
Rouse. The FOA further submits that Rouse's metering events relate to both actual time of use of a 
streaming media file and/or to an estimated time of use. (See, FOA, pg. 3, lines 16-18.) The FOA 
further refers to Fig. 1 and paragraphs 5, 35, 44, 95, 97, and 143 of Rouse. Applicant respectfully 
contends that, even if Rouse discloses both types of metering events, Rouse does not disclose or 
suggest applicant's invention as defined by the limitations of the independent claims. 

For example, with regard to independent Claims 1. 1 1, and 21, the FOA indicates that 
Rouse discloses the limitation of transmitting a metering URL from a first server to a client player 
over a network. The FOA cites Figs. 3 and 4, and cites paragraphs 6, 7, and 1 1 . With regard to 
these cited portions and all other cited portions of Rouse, the FOA does not identify which terms of 
Rouse allegedly correspond to the terms of the claim limitations. The FOA states in an Examiner's 
Note that "Examiner has cited particular columns and lines numbers . . ." In reality, the FOA cites 
whole figures and whole paragraphs, since the cited references are publications. However, these 
citations do not identify which terms of Rouse allegedly correspond to the terms of the claim 
limitations. For that reason alone, the finality of the rejections should be withdrawn, so that 
Applicant has a fair opportunity, as required under the Administrative Procedures Act (APA), to 
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responds to the adverse action of the US Patent and Trademark Office as a federal agency. In this 
specific example, Applicant respectfully disagrees that any portion of Rouse discloses or suggests a 
metering URL. 

Because the FOA does not identify which term of Rouse correspond to the claimed 
metering URL, applicants have reviewed Rouse for possible equivalents. Applicants find none. It 
appears that the FOA may be interpreting Rouse's Protected Link as the claimed metering URL. In 
cited paragraph 11, Rouse states that "a Player receives a direct Stream connection to the Protected 
Link of a Protected Webcast Server . . " (Rouse, pg. 1, para. 11.) Rouse defines a Protected Link 
as "[a] URL that provides a direct connection to a protected Webcast Stream residing on a Webcast 
or Web Server." (Rouse, pg. 3, para. 69.) Rouse also defines a Stream as "[t]he digital data that is 
continually transmitted to a player or Client which upon receipt of the data converts the data to a 
final intended Client Side presentation such as audio, video, or multimedia presentation." (Rouse, 
pg. 4, para.79.) This does not disclose or suggest the claimed metering URL. 

This term should be read in view of the specification, which explains an example 
embodiment in which "a metering URL 127 U points to a user meter located in the media frame 
server. . . Metering URL 127 includes a variety of arguments that identify the host, the path to the 
meter, and the meter description." (Spec, pg. 14, lines 2-11.) A "client media player concatenates 
the metering URL and the embedded metering event, step 710, and pushes them up to the 
mediaframe servers, which cause a user meter to be ticked/decremented, step 715." (Spec, pg. 17, 
lines 31-33.) Applicant is not attempting to incorporate the above specification language into the 
claims, and there is no requirement to incorporate additional limitations when the applicant acts as 
his own lexicographer. However, the meanings of the existing claim terms are understood in view 
of the specification. It is clear that Rouse's Protected Link to a Stream of audio, video, or 
multimedia data does not disclose or suggest the claimed metering URL to a user meter that 
ticks/decrements based on an embedded metering event. 

As an alternative, the FOA might be interpreting the metering URL as Rouse's 
RequestURL, which is mentioned in cited Figs. 1 and 4. Rouse does not provide an expressed 
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definition of the RequestURL. However, Rouse explains that "[a]n embedded Player's Webcast 
Stream URL parameter is set equal to a specific URL controlled on the Server side. This variable is 
labeled RequestURL in FIG. 1." (Rouse, pg. 4, para. 78.) The text of cited Fig. 3 further explains 
that: 

D - stream player connects to RequestURL in metafile which goes to web server 
E - web server redirects RequestURL to ProtectURL at webcast server 
F - webcast server sends webcast stream to subscriber's stream player 

Rouse defines ProtectURL as the Protected Link. (See Rouse, pg. 3, para. 69.) Thus, RequestURL 
is simply a link for redirecting to the Protected Link, which directs a subscriber's stream player to a 
Stream of audio, video, or multimedia data. There is no disclosure or suggestion that the 
RequestURL identifies or refers to anything related to the claimed metering URL to a user meter. 

Applicant also disagrees that Rouse discloses or suggests the claimed limitation of 
receiving an embedded metering event in the streaming media file. In response to Applicant's prior 
arguments, the FOA states that "Rouse is based on a metering event in the media stream (see fig. 1 
for various timer events) . . » (FOA, pg. 3, lines 12-13.) Again, the FOA does not identify any 
particular event in Fig. 1 or any other term in Rouse that corresponds to the claimed embedded 
metering event in the stream. It is not Applicant's duty to guess which event that the FOA refers to, 
or to disprove every event listed in Fig. 1 of Rouse. Nevertheless, Applicant has reviewed Rouse 
for each event listed in Fig. 1 , and none of the events listed are embedded in the media stream. 

The left-most box of Fig. 1 is titled "Server Side Code Encodes These Access Strings 
(101). However, the Access Strings are not encoded into the media stream. Rouse defines Access 
Strings as "[t]he alphanumeric names of Server Side elements as opposed to the physical elements 
themselves such as files, file entries and directories." (Rouse, pg. 2, para. 33.) Rouse also defines 
the Access Elements as «[p]hysical Server Side components such as files, file entries and directories 
used to access a requested connection, for example, to a Protected Webcast." (Rouse, pg. 2, 
para. 31.) Thus, Rouse does not disclose or suggest that access strings are embedded as metering 



{S:\TM\FORMS\80050782.DOC UlUlWilDIIira } 



PAGE 11/15 * RCVD AT 2/9/2006 7:08:28 PIV! [Eastern Standard Time] * SVR:USPTO-EFXRF^/24 * DNIS:2738300 * CSID:2062628901 * DURATION (mm-ss):04-00 



02/09/2006 17:08 FAX 2062628901 



DARBYFAX2 



-» USPTO MAIN 



11012 



Application No, 10/680,507 10 Docket No.: 08226/1203564-US1 

events in the media stream. Applicant finds no other box on Fig. 1 that discloses or suggests 
embedding. 

The bottom right corner of Fig. 1 states that "Billing [is] calculated as time period 'TX' 
or the estimated time that the player or plug-in is streaming the protected webcast between the 
subscriber's start and stop requests." Clearly, the subscriber's start and stop requests are not 
embedded in the media stream. 

The only other possible alternative appears to be the time period TX. Rouse explains 
that "the time period 'TX' represents the Billing time period which is estimated to be the duration of 
the Client Side Player connection to the ProtectURL." (Rouse, pg. 8, para. 138, emphasis added.) 
An estimated connection duration does not disclose or suggest an embedded metering event in the 
streaming media file. 

Cited paragraph 143 of Rouse also states that: 

The new items are: ... a means to charge Internet customers in Real Time 
for the delivery and actual metered use of Content ... 5) a means to charge the 
subscriber either a fixed fee for use of Protected Content or a fee determined in 
Real Time by the Subscriber's actual use of the Protected Content such as a 
continuous Stream Webcast. 

However, Rouse does not disclose or suggest that the means include embedded metering events in 
the streaming media file. As discussed above, none of the events listed in Fig. 1 of Rouse are 
embedded in the media stream. The only other related means is the time period TX, which is a 
connection time, not an embedded metering event in the media stream. Despite Rouse's reference 
to "actual metered use," Rouse does not disclose or suggest the claimed embedded metering event 
in the streamlining media file. 

Similarly, Rouse does not disclose or suggest ticking the user meter in a server based on 
receipt of the streaming media file and the embedded metering event. Rouse does not disclose or 
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suggest that any metering is done by a server. The FOA cites Fig. 1 , and paragraphs 35, 44, 95, 97, 
and 101 . However, neither these paragraphs, nor any other part of Rouse discloses that ticking a 
user meter is done in a first server that transmits a metering URL. The cited paragraphs disclose a 
"Subscriber Control Web Page . . . controlled by the Subscriber service Web Server . . ." (Rouse, 
pg. 5, para. 95.) However, Rouse explains that the "Subscriber control Web page [] allows the 
Subscriber to . . . start and stop Billing in conjunction with the use of a Protected Webcast . . ." 
(Rouse, pg. 5, para. 95.) Alternatively, Rouse discloses a "Web page that controls the embedded 
Player." (Rouse, pg. 5, para. 101.) An embedded Player is not related to an embedded metering 
event. Thus, there is no disclosure or suggestion that this web page ticks a user meter in the first 
server based on receipt of the streaming media file and the embedded metering event. For that 
matter, Rouse also does not disclose or suggest that ticking is done in a second server that streams 
the streaming media or in a client side browser or plug-in. Even if Rouse discloses metering the use 
of streaming media, Rouse does not disclose or suggest where (or how) the metering is performed as 
claimed. 

Accordingly, the rejection of independent Claims 1, 11, and 21 under 35 U.S.C. §102(b) 
should be withdrawn. Because dependent claims are patentable for at least the same reasons as their 
corresponding independent claims, the rejection under 35 U.S.C. §102(b) of dependent Claims 2-7, 
and 12-17 should also be withdrawn. 

Independent Claims 22 and 28 include similar, although different, limitations than those 
of independent Claims 1, ll,and21. For example, Claim 22 includes the limitation of a metering 
URL, wherein a target of the metering URL is a user meter. As discussed above, Rouse does not 
disclose or suggest a metering URL directed to a user meter. Claims 22 and 28 include a limitation 
of an embedded media event included in a streaming media. As discussed above, Rouse does not 
disclose or suggest an embedded media event. For at least the reasons above, the rejection of 
independent Claims 22 and 28 under 35 U.S.C. §102(b) should be withdrawn. Because dependent 
claims are patentable for at least the same reasons as their corresponding independent claims, the 
rejection under 35 U.S.C. §l02(b) of dependent Claims 23 and 24 should also be withdrawn. 
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Claim Rejections - 35 U.S.C. 103 over Rouse & Shamoon 

Dependent Claims 8, 18, and 26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Rouse in view of Shamoon et al. (U.S. Patent Application Publication No. 
2004/0107356). The FOA indicates that Shamoon discloses signing a metering URL with a 
message authentication code (MAC). However, Shamoon uses a MAC for the streamed data and 
does not disclose or suggest a metering URL. Specifically, Shamoon explains that "Cryptographic 
Engines operate under control of Control Block 13 to decrypt and/or cryptographically validate 
(e.g., perform secure hashing, message authentication code, and/or digital signature functions) the 
encrypted packet streams . . (Shamoon, pg. 4, para. 72.) Neither Shamoon nor Rouse disclose or 
suggest the claimed metering URL. Thus, any combination of Shamoon and Rouse will not disclose 
or suggest signing a metering URL with a MAC. In addition, Shamoon does not disclose or suggest 
the other limitations discussed above with regard to the independent claims. Accordingly, the the 
rejection of dependent Claims 8, 1 8, and 26 under 35 U.S.C. §103(a) should be withdrawn. 

Claim Re jections - 35 U.S.C 1 03 over Ro use. Shamoon & Tewari 

Dependent Claims 9, 10, 19, 20, and 27 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Rouse in view of Shamoon, and further in view of Tewari et al. (U.S. Patent 
Application Publication No. 2003/0097564). With regard to Claims 9 and 19, the FOA indicates 
that Tewari discloses verifying the authenticity of the URL. However, the URL of Tewari is 
directed to content, and not to the claimed metering URL. None of the cited references disclose or 
suggest a metering URL. Thus, any combination of the cited references does not disclose or suggest 
verifying the authenticity of the metering URL. 

With regard to dependent Claims 10, 20, and 27, the FOA indicates that Tewari discloses 
that a MAC is an MD5 hash or a SHA1 hash for signing the metering URL with a MAC As 
discussed above, none of the cited references disclose or suggest a metering URL. Thus, any 
combination of the cited references does not disclose or suggest that a MAC is an MD5 hash or a 
SHA1 hash for signing the metering URL with a MAC. In addition, Tewari does not disclose or 
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suggest the other limitations discussed above with regard to the independent claims. Accordingly, 
the rejection of dependent Claims 9, 10, 19, 20, and 27 under 35 U.S.C. §103(a) should be 
withdrawn. 
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